Calendaring location-based events and associated travel

ABSTRACT

A user interface for an electronic calendar represents different locations or different users or different user calendars in different portions of the display. Calendar entries can be associated with one or more locations, one or more users, and with one or more user calendars. The different locations may reside in different time zones and a timeline for each time zone is displayed. The position of the calendar entry provides a visual identifier of the timeline with which the event is associated. Travel time to and from events in the calendar are calculated for calendared events and shown adjacent to the beginning and end of the event. A user&#39;s future location at a point in time is inferred from patterns in the user&#39;s locations and by analyzing the user&#39;s calendared events and correspondence in order to calculate travel time to calendared events.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.12/624,682, filed on Nov. 24, 2009, which is a continuation of U.S.application Ser. No. 12/568,354 filed on Sep. 28, 2009, which claims thebenefit of U.S. Provisional Patent Application No. 61/142,875, filedJan. 6, 2009, which is hereby incorporated by reference in its entirety.This application is related to U.S. patent application Ser. No.12/512,854, filed Jul. 30, 2009, entitled “Data-Oriented User Interfacefor Mobile Device,” and U.S. patent application Ser. No. 12/512,752,filed Jul. 30, 2009, entitled “Social Network Model for SemanticProcessing” which are incorporated by reference in their entirety.

BACKGROUND 1. Field of the Invention

The present invention relates to electronic calendars.

2. Description of the Related Art

Users commonly maintain electronic calendars in order to track scheduledappointments, organize meetings, provide reminders to attend plannedevents, and for the convenience of sharing their availability withothers through allowing others to view the electronic calendar. Althoughelectronic calendars are convenient for helping users avoid beingdouble-booked for activities occurring at the same time, conventionalelectronic calendars do not adequately account for implicit conflictscreated by the locations of various meetings. For example, schedulingtwo adjacent meetings or events that occur in different places may notallow enough time to travel between the events.

To address the travel time issue, users have developed a variety ofapproaches, each with respective drawbacks. First, users may choose notto show travel times between events on their calendar. Drawbacks of thisapproach include the risk of forgetting about or wrongly estimating thetravel time required to arrive at an event and leaving too late. Also,other users viewing the calendar may attempt to schedule a meeting withthe user for the slot that was intended by the user for travel toanother meeting because the slot appeared to be free.

Second, users may extend the existing meeting to account for the traveltime needed to and from the meeting. Drawbacks of this approach includethe risk that the user may incorrectly estimate the travel time, and/orforget the actual start time of the meeting. Also, should the meeting berescheduled, the user must perform the same estimations and extensionagain. This approach also hinders the user's ability to invite others tothe meeting, since the meeting period reflects the user's own traveltimes and the travel times may vary for others travelling from differentlocations.

Another approach involves the user manually entering an appointmentimmediately before and an appointment immediately after any meeting thatrequires travel in order to block off an estimated travel period on theelectronic calendar. This approach is cumbersome for those who travelfrequently as any meeting that requires travel becomes a requirement tocreate three calendar entries that each must be moved if the meeting isrescheduled. This approach also still suffers from the drawbackmentioned above regarding the risk that the user may incorrectlyestimate the travel time.

SUMMARY

Embodiments of the invention provide methods, systems, and computerprogram products for an electronic calendar that recognizes events onthe calendar occur at locations and accounts for travel between thelocations for the calendared events. In one embodiment, a user interfacefor the electronic calendar represents different locations in differentportions of the display. Calendar entries, such as a conference call ora plane flight, can be associated with one or more location, such as thelocations of all conference call participants or the departure andarrival cities for the flight. In one particular embodiment, thedifferent locations reside in different time zones and a timeline foreach time zone is displayed. The position of the calendar entriesprovides a visual identifier to the user of the timeline with which theevent is associated.

In another embodiment, travel time to and/or from events in the calendarare calculated for calendared events. The time estimated for travel toan event can be shown adjacent to the beginning of the event and thetime estimated for travel from the event can be shown adjacent to theend of the event.

In another embodiment, a user's future location at a point in time isinferred from observing patterns in the user's activities and locationsas well as by analyzing the user's calendared events and correspondence.By inferring where a user is likely to be traveling from in order toarrive at an event, an estimate can be made as to the appropriate amountof time to allot in the calendar for travel to the event. By inferringwhere a user is likely to be traveling after an event, an estimate canbe made as to the appropriate amount of time to allot for travel after acalendared event.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram of the computing environment, inaccordance with an embodiment of the invention.

FIG. 2A is a block diagram of a server, in accordance with an embodimentof the invention.

FIG. 2B is a block diagram of a location inference module, in accordancewith one embodiment of the invention.

FIG. 3 is a high-level block diagram illustrating an example of acomputer for use as a user device or server, in accordance with anembodiment of the invention.

FIG. 4 is an illustration of a user interface displaying a calendarshowing events in two locations in different time zones, in accordancewith an embodiment of the invention.

FIG. 5 is an illustration of a user interface displaying a calendarshowing events in three locations in three different time zones, inaccordance with an embodiment of the invention.

FIG. 6 is an illustration of a user interface displaying a calendarshowing events in three locations within the same time zone, inaccordance with an embodiment of the invention.

FIG. 7 is an illustration of a user interface displaying a calendarshowing events for three users, wherein some events are shared eventsbetween multiple users, in accordance with an embodiment of theinvention.

FIG. 8 is a flow chart illustrating a method of inferring a location ofa calendar event, in accordance with an embodiment of the invention.

One skilled in the art will readily recognize from the followingdiscussion that alternative embodiments of the structures and methodsillustrated herein may be employed without departing from the principlesof the invention described herein.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Embodiments of the invention provide methods, systems, and computerprogram products for an electronic calendar that recognizes events onthe calendar occur at locations and accounts for time needed to travelbetween the locations for the calendared events. The electronic calendarmay be accessed through an application on a mobile device such as a“smart phone” or a laptop that is equipped with GPS or other locationdetermination technology. Thus, as the user carries the device fromplace to place throughout the day, the user can access the user'scalendar and the device can track the user's location. Throughrecognizing patterns in the user's locations and from analyzing theuser's calendared events and the user's correspondence, the user'sfuture location can be inferred, thus enabling estimates of travel timesto events on the calendar from the user's likely starting location andestimates of travel times from events on the calendar to the user'slikely next destination.

FIG. 1 is a high-level block diagram of the computing environment 100 inaccordance with an embodiment of the invention. The computingenvironment 100 includes a server 120 that is connected via a network101 to a user device 110. The network 101 is a communications networksuch as a local area network, a wide area network, a wireless network,an intranet, or the Internet. In one embodiment, the computingenvironment 100 also includes a web server 130 that serves web pages tothe user device 110 and a message server 140 that serves messages suchas email or SMS messages to the user device 110. Although only one userdevice 110 and a limited number of servers are shown in FIG. 1 forclarity, any number and type of user devices and server configurationsmay be connected to the network 101.

In one embodiment, data flowing to and from the user device 110 passesthrough the server 120. For ease of reference, the term “document” willbe used herein to refer to a discrete collection of data, such as anappointment request, an email, a web page, a message, a file, or anyother type of electronic document. The term “correspondence” will beused herein to refer to any document that contains a message sent by theuser or received by the user, such as an email, a text-message, anappointment request, or the like. The server 120 analyzes the documentsflowing to and from the user device 110 in order to extract entitiesfrom the data and to recognize events. Entities are data objects thatrepresent people, organizations, locations, or other real world items.Entities have properties associated with them, such as aliases,addresses, latitude/longitude coordinates, points of contact for theentity, and the like. The server 120 extracts the entities from thedocuments and passes the entity information to the user device 110 sothat the user device 110 can offer to the user contextually-relevantactions with respect to the entities, as described by U.S. patentapplication Ser. No. 12/512,854, filed Jul. 30, 2009, entitled“Data-Oriented User Interface for Mobile Device,” which has beenincorporated herein. The server 120 also extracts event information froman analysis of the user's correspondence for use in adding to calendarentries. The server 120 also tracks the user's location from locationinformation received from the user device and can infer the user'sfuture location at various times based on patterns in the trackedlocations, the user's calendared events, and the user's analyzedcorrespondence.

In various embodiments, the user device 110 may be any device capable ofcommunicating over the network 101. Examples of a user device 110include a personal digital assistant (PDA), a mobile device with limitedfunctionality or a “smart phone” mobile device that offers broadfunctionality such as large memory storage and an advanced userinterface, and any portable computer. In one embodiment, the user device110 is a “smart phone” device that offers broad functionality. Forexample, the device may track calendar appointments, provide GPS orother location determination functionality, send and receive SMSmessages and email, offer web access, manage contact information, andmanage and communicate other types of documents.

The user device 110 has a graphical user interface 111 that allows auser to access and interact with data stored on the user device to makeuse of the device's functionality. The graphical user interface 111allows users to view information and select information, for example, byclicking on it, touching it, highlighting it with a cursor, or any othermethod of selecting a portion of the displayed information. Thegraphical user interface 111 can be used to display and edit the user'scalendar and details about the calendar entries. Examples of the userinterface 111 are described below with reference to FIGS. 4-7. In oneembodiment, the graphical user interface 111 also includes node menusthat contain actions relevant to a selected entity and/or spinners whichallow a user to simultaneously view information from a variety ofapplications that is relevant to an entity, both of which have beendescribed in U.S. patent application Ser. No. 12/512,854, filed Jul. 30,2009, entitled “Data-Oriented User Interface for Mobile Device,” whichhas been incorporated by reference in its entirety.

In this example, in addition to the graphical user interface 111, theuser device 110 includes various applications 113 that support thefunctionality of the user device 110. For example, the user device 110may include a calendar application 114 and telephone, email, contactmanager, browser, word processing, map browser, spreadsheet, and/orother business or personal applications. A user of the user device 110may create, receive, send, access, store, or otherwise interact withdata through the applications 113. Specifically, the user can use thecalendar application 114 to schedule, view and update calendar entries,and send meeting requests to others. As will be described in more detailbelow, the calendar application 114 recognizes that some events are tiedto specific locations and the electronic calendar represents differentlocations in different portions of the display. Calendar entries, suchas a conference call or a plane flight, can be associated with one ormore locations, such as the locations of all conference callparticipants or the departure and arrival cities for the flight. In oneparticular embodiment, the different locations may reside in differenttime zones, and the calendar application 114 displays the relative localtime for calendar entries in association with the calendar entries.

The user device 110 also includes a location determination module 115.The location determination module 115 determines the current location ofthe user device 110, for example from received GPS and/or cellularsignals and/or any other location determination method known to those ofskill in the art. In one embodiment, the location determination module115 determines the location of the user device in terms of latitude andlongitude.

The user device 110 also includes a server interaction module 112 tomanage the communications between the server 120 and the user device110. Specifically, the server interaction module 112 receives data sentto the user device 110 from the server 120, including, in oneembodiment, metadata identifying extracted entities within the data andrecognized events. The server interaction module 112 also receives datato be sent to the server 120 from the user device 110, for exampleoutbound email and text messages and the determined location of the userdevice 110 from the location determination module 115.

FIG. 2A is a block diagram of a server 120, in accordance with anembodiment of the invention. The server 120 analyzes data flowing to andfrom the user device 110 in order to extract entities and recognizeevents. In this example, the server 120 includes an entity extractionmodule 124, an index module 125, a social network module 129, an eventrecognition module 126, a location tracker 123, a location inferencemodule 127, a storage module 128, a message agent 122, and a deviceinteraction module 121.

The entity extraction module 124 identifies entities from data flowingto and from the user device 110. The entity extraction module 124 parsestext in a document in order to identify entities. For example, locationnames, names of people, and names of organizations are extracted basedon full natural language processing, whereas phone numbers, emailaddresses, and URLs are extracted based on regular expressions, anddates and times are extracted based on a set of rules. In oneembodiment, the entity name may be an alias of the word or words thatappear in the text that undergoes analysis by the entity extractionmodule 124. In one embodiment, the entity type is one of person,organization, location, or other. The entity name and type may be outputfrom the entity extraction module to storage 128 and/or communicated tothe user device 110 through the device interaction module 121 of theserver 120.

The index module 125 indexes the data according to the entitiesextracted by the entity extraction module 124, in one embodiment. Incases where a document contains more than one extracted entity, thedocument may be indexed under each extracted entity. The index module125 may store the results of the indexing in a local storage 128 orremote storage (not shown).

The social network module 129 builds the social network model implicitin the user's data, such as from contacts, email, web pages, as well asother types of documents. The social network model is a description ofthe relationships between the entities that are found in the user'sdata. The social network model adjusts the strength of relationshipsdetermined to exist between entities, particularly people entities. Theserver 120 uses the user's social network model, for example, to aid inentity extraction and to aid in identifying entities from an ambiguousreference in the user's data, as described in U.S. patent applicationSer. No. 12/512,752, filed Jul. 30, 2009, entitled “Social network Modelfor Semantic Processing” which has been incorporated by reference. Thesocial network module 129 stores the social network model in storage128.

The message agent 122 receives inbound messages from message server 140and outbound messages from the user device 110. The message agent 122may also act as a mail transfer agent in routing messages betweenservers and mail clients. The message agent 122 provides the server 120with the ability to intercept and process messages passing betweendevices on the network 101.

The event recognition module 126 recognizes events from data flowing toand from the user device 110, including the user's correspondence. Theevent recognition module 126 parses text in a document in order toidentify appointments, meeting requests, flight reservations, anditineraries. A variety of techniques can be used to recognize events andextract event information from the parsed text. In one embodiment, amachine learning algorithm uses features such as the presence of date,time, location, people and other entities, and the presence of phrasessuch as “meet”, “get together”, and the like to learn a model forrecognizing when a document refers to an event. The event informationmay comprise a time period, one or more locations, and one or moreparticipants. The event information may be output from the eventrecognition module 126 to storage 128 and/or communicated to the userdevice 110 through the device interaction module 121 of the server asmetadata associated with the document. In one embodiment, when the userviews a document with associated event metadata, the user interfaceprovides a mechanism to create a new event in the calendar using theassociated metadata. metadata. In one embodiment, entities related tothe event are highlighted; when the user selects a highlighted entity, anode menu appears including an option to create a new eventincorporating the metadata. Node menus are discussed in more detail inU.S. patent application Ser. No. 12/512,854, filed Jul. 30, 2009,entitled “Data-Oriented User Interface for Mobile Device,” which hasbeen incorporated herein by reference.

The location tracker 123 receives information regarding the location ofthe user device 110 from the location determination module 115 of theuser device 110. For example, the location tracker 123 may receive astream of coordinates derived from GPS signals or from cellular or otherlocation determination technologies. In one embodiment, the location ofthe user's device 110 is tracked every 10 minutes. In other embodiments,the location may be tracked more or less frequently. Generally, a higherfrequency of location determinations results in more accurate locationdata but a shorter battery life for the device 110. The location tracker123 may store the user's location data in storage 128.

The location inference module 127 infers the future location of the userbased on prior patterns, the user's calendared events, and the user'scorrespondence. The location inference module 127 is described ingreater detail with reference to FIG. 2B.

The device interaction module 121 manages the communications between theserver 120 and the user device 110. Specifically, the device interactionmodule 121 receives documents from, for example, web server 130 ormessage server 140 through message agent 122, or from other locations onthe network 101, to be sent to a user device 110. In one embodiment, thedevice interaction module 121 also receives metadata identifyingentities within documents from the entity extraction module 124 andevent information from event recognition module 126. The deviceinteraction module 121 also receives data from the user device 110 forsubsequent processing by the server 120, including the locationinformation from the location determination module 115 of the userdevice 110.

FIG. 2B is a block diagram of a location inference module 127, inaccordance with one embodiment of the invention. The location inferencemodule 127 infers the user's future location based on prior patterns,the user's calendared events, and the user's correspondence. Thelocation inference module 127 includes a place identification module1271, a place naming module 1274, a shadow calendar module 1272 and atravel time estimation module 1273.

The place identification module 1271 identifies places of importance inthe user's saved location data. A place of importance is anywhere theuser stops for a while or spends a significant amount of time. In oneembodiment, a place is defined as a map point (for example, expressed inlatitude/longitude coordinates), a distribution around that point (forexample, a circle of fixed radius or a normal distribution with acertain standard deviation), and, optionally, one or more names. In oneembodiment, a place is created for anywhere the user stops for at least30 minutes, and places are discovered by clustering recorded locationpoints to find these places. Places may be initially unnamed, untilprocessed by the place naming module 1274. Places may have an associatedhistory which tracks the when, how often, and for how long the user hasvisited the place; places with longer histories may be made moreprominent in the user interface. Addresses discovered in the user's datamay also be considered to be places; the address can generally beconverted to map coordinates.

The place naming module 1274 correlates places identified by the placeidentification module 1271 with place names from the user, place namesfrom the user's data, publicly-available business and place names, andother sources in user calendar entries 12701 and user event data 12702extracted by the event recognition module 126 of the server 120, and bycoordinates or other user location data 12703 received by the locationtracker 123 of the server 120. The place naming module 1274 trackspossible names for identified places. A single place may have multiplevalid names (such as “The White House” and “The President's house”); inaddition multiple places with different names may appear as the samelocation due to the limitations of the device's location technology.

The place naming module 1274 can associate names with places in variousways. The user may choose to associate a name with an address or maplocation; in one embodiment, the user may be prompted to name placeswith extensive history. The user may also choose to add both a placename and an address or map location (as indicated via a map browsingapplication) to a calendar event; this creates an implicit association.An association may also be created when the user has a calendar eventthat lists a location name and his location log shows him to be atcertain map coordinates during that time. Similarly, the user'scorrespondence may refer to an event that corresponds to a particularplace and time found in the user's location log. Finally, associationsmay also be generated by using publicly-available location data to findpossible names. All of these examples provide evidence of alocation-name association; the place naming module maintains a“confidence” in every association by combining and weighing theavailable evidence. Places and names may be shown to the user only whenthe confidence reaches a threshold.

The shadow calendar module 1272 uses patterns in the user location data12703 to create a typical routine generally followed by the user. Insome cases, places with special meaning to a user, such as “work” and“home” can be inferred from patterns in the user's locations. Forexample, John lives in West Seattle and works downtown. The shadowcalendar module 1272 has observed that he is typically in one locationat night and the other during weekdays. Thus, the shadow calendar module1272 may associate the names “home” and “work” with these places, andcreate a typical schedule for the user being at “home” and at “work.”The typical schedule of where the user is throughout the day, week,month, or other time period is referred to herein as the user's “shadowcalendar.” By observing the user's typical locations, the shadowcalendar module 1272 can infer where the user is likely to be in thefuture according to the same pattern, unless another event from the usercalendar entries 12701 or user event data 12702 is scheduled to alterthe pattern. Thus, events scheduled by the user can supersede events inthe shadow calendar.

In one embodiment, the shadow calendar module 1272 creates “patterns”that consist of a place, a time span, a recurrence, and a probability. Aplace refers to any place identified and named by modules 1271 and 1274.A time span might be a range of times, with a distribution representingvariance around the endpoints. Typical recurrences include daily,weekly, every weekday, and the like. Finally, the probability representsthe percentage of the time the user has been observed to be in thatplace during those time spans (and thus a projected future probabilityof finding him there). For example, John's “work” pattern would consistsof the place that has been identified as “work”, the time span 9:00 am-5:00 pm with a normal distribution to represent that he sometimesarrives or leaves earlier or later, the recurrence “every weekday”, andthe probability 0.67 because John is often out of the office formeetings—about one third of the time.

The travel time estimation module 1273 estimates the travel time neededto travel to and from a calendared event. The travel time to the eventcan be estimated from where the user currently is, for example asreported through the user location data 12703, from a departure pointthat the user explicitly adds to the event data, or from where the useris predicted to be in advance of the calendared event based on the usercalendar entries 12701, user event data 12702 or the shadow calendarcreated by the shadow calendar module 1272. Similarly, the travel timeneeded after the event can be estimated based on the location of thenext calendared event based on the user calendar entries 12701 and theuser event data 12702, or to where the user is predicted to be headingbased on the shadow calendar created by the shadow calendar module 1272.

The travel time estimation module 1273 may receive map data 12704,business and organization data 12705, directions and route data 12706,traffic data 12707, and user location data 12703 as inputs to preparingtravel time estimations. The map data 12704 and business andorganization data 12705 can help identify the coordinates of thelocation for the event. For example, if the event is at Stella's Café inSeattle, the business and organization data 12705 can identify thestreet address for the restaurant. The map data 12704 can correlate thestreet address for the restaurant to a geospatial location, for examplein coordinates. The directions and route data 12706 can plan the routebetween the user's starting location and the geospatial location ofStella's Café. The directions and route data 12706 may includedirections and routes for multiple modes of transportation, such aswalking, cycling, taking mass transit (e.g., bus, trolley, train,ferry), or driving. Traffic data can be used to estimate which routeamong several possibilities (e.g., surface streets versus a freeway, ora train versus driving) is the fastest to Stella's Café, and ultimatelyhow long the travel time is expected to be. Lastly, observed travel timefrom any of the user's previous visits to this location, particularly atthe same departure time, can influence the travel time estimate. In oneembodiment, the system uses the user location data 12703 to compute andrecord the travel time for every route the user travels. When a futuremeeting calls for a route the user has traveled before, the travel timemay be estimated as the average travel time of all previous trips alongthat route. The average may be computed as a weighted average, where thecloser the trip was in time of day to the planned trip, the greaterweight that trip has in determining the projected time. For example,suppose the user is planning a meeting at Stella's Café for noon on thenext day. He may have traveled to there from work five times previously,three times at around noon and twice at 6:00 pm. When predicting thetravel time, the system may weight the travel time of the three noontrips more than that of the two evening trips. The travel time estimatescan be presented to the user as blocks of time immediately adjacent tothe calendared appointments, as will be shown and described withreference to FIGS. 4-7 below. These estimates can be dynamicallyupdated, for example, in response to changing traffic conditions, andthe corresponding length of the blocks of time adjacent to thecalendared appointments are updated accordingly.

FIG. 3 is high-level block diagram illustrating an example of a computer300 for use as a server 120 or user device 110, in accordance with anembodiment of the invention. Illustrated are at least one processor 302coupled to a chipset 304. The chipset 304 includes a memory controllerhub 350 and an input/output (I/O) controller hub 355. A memory 306 and agraphics adapter 313 are coupled to the memory controller hub 350, and adisplay device 318 is coupled to the graphics adapter 313. A storagedevice 308, keyboard 310, pointing device 314, and network adapter 316are coupled to the I/O controller hub 355. Other embodiments of thecomputer 300 have different architectures. For example, the memory 306is directly coupled to the processor 302 in some embodiments.

The storage device 308 is a computer-readable storage medium such as ahard drive, compact disk read-only memory (CD-ROM), DVD, or asolid-state memory device. The memory 306 holds instructions and dataused by the processor 302. The pointing device 314 is a mouse, trackball, or other type of pointing device, and is used in combination withthe keyboard 310 to input data into the computer system 300. Thegraphics adapter 313 displays images and other information on thedisplay device 318. In some embodiments, the display device 318 includesa touch screen capability for receiving user input and selections. Thenetwork adapter 316 couples the computer system 300 to thecommunications network 101. Some embodiments of the computer 300 havedifferent and/or other components than those shown in FIG. 3.

The computer 300 is adapted to execute computer program modules forproviding functionality described herein. As used herein, the term“module” refers to computer program instructions and other logic used toprovide the specified functionality. Thus, a module can be implementedin hardware, firmware, and/or software. In one embodiment, programmodules formed of executable computer program instructions are stored onthe storage device 308, loaded into the memory 306, and executed by theprocessor 302.

The types of computers 300 used by the entities of FIG. 1 can varydepending upon the embodiment and the processing power used by theentity. For example, a mobile device 110 that is PDA typically haslimited processing power, a small display 318, and might lack a pointingdevice 314. The server 120, in contrast, may comprise multiple bladeservers working together to provide the functionality described herein.

FIG. 4 is an illustration of a user interface 400 displaying a calendarshowing events in two locations in different time zones. The userinterface 400 allows the user to view a visual representation ofcalendar entries according to the location in which the eventsrepresented by the calendar entries occur and the local time at whichthey occur. The user interface 400 is divided into two portions: theportion on the left 441 corresponding to Pacific Standard Time, and theportion on the right 442 corresponding to Central Standard Time. In theexample, these time zones have been chosen because the user is currentlyin Seattle, in the Pacific time zone, and will be traveling to Chicago,in the Central time zone. The user may manually select these time zones,or allow the device to select them automatically, based on the locationsof calendar events during the day being viewed.

A timeline 443 corresponding to Pacific Standard Time is placedvertically within the portion on the left 441, and a timeline 444corresponding to Central Standard Time is placed vertically within theportion on the right 442. Each timeline 443, 444 displays numberscorresponding to times in the respective time zone. Calendared eventsare shown as enclosed shapes that overlap one or more of the timelines443, 444 associated with the different locations. In this embodiment,the position of events on the left or the right portion of the screenprovides a visual identifier to the user regarding which timeline theevent is associated with, and thus, which timeline the event originatedfrom or is connected to. In this example, the shape of events isrectangular with rounded corners, but any other shape may be usedadditionally or alternatively. The start and end times for an event arerepresented respectively by where the top edge and bottom edge of theshape crosses the timeline 443, 444. Thus, the vertical extent of theshape is correlated to the length of the event. The horizontal placementand extent of the shape represents the location or locations which isrelevant to the event, as will be described in more detail below. Inaddition, each shape may contain a text description of the event toidentify the event to the user. Each event may be associated withadditional information that may or may not be displayed to the user,including other participants in the event, the location of the event,the exact start time and end time of the event, the organizer of theevent, and/or any other information that is generally tracked withrespect to calendar entries, as known to those of ordinary skill in theart.

The first calendared appointment for the user on Friday, Apr. 9, 2010 isa conference call 401 between Seattle and Chicago. The user interface400 allows the user to quickly grasp what time it is in Seattle andChicago for any calendar entry by viewing the timelines 443, 444 downthe left 441 and right 442 sides of the display. In one embodiment,events that do not have to take place in any specific location areidentified in a different color or otherwise distinguished from eventsthat are tied to specific locations. In the example shown in FIG. 4,events that do not have to take place in any specific location, forexample calls 401, 404, and 409, are surrounded by a “time box” havingdotted lines. The dotted lines overlap the timelines relevant for thepeople participating in the event (i.e., the call participants) but donot require the participants to be at any particular location. Thus,when the user has the conference call 401, the user is calling fromSeattle to Chicago, so the event 401 overlaps both timelines 443 and444, despite the fact that the user could be anywhere in Seattle or evenen route to another city while making the call. Again, the position ofthe event “time box” relays important information regarding timelines tothe user: especially which timelines are relevant to that event. Becausethe user may participate in these events while en route, they may bescheduled to overlap with travel time without a conflict; in oneembodiment, the user is warned of the overlap and may choose whether toschedule the event. For example, the user may choose to make theconference call 401 while en route to the airport for his flight.

After the call 401, the user has a flight 403 scheduled from Seattle toChicago. The flight event 403 is represented as an enclosed shapeoutlining an area that spans the timelines 443, 444 associated with bothSeattle and Chicago because the flight takes off in one location andlands in the other, and is thus relevant to both timelines. The traveltime to get to the airport for the flight event 403 is shown by calendarentry 402 adjacent to the upper edge of the flight event 403. In thisembodiment, the user can quickly view the duration of the flight by thevertical extent of the shape 403 and quickly grasp the total time theuser will be in transit from the combination of the travel time 402 andflight event 403. Optionally, the travel time 402 may be displayed asspanning the entire width of the associated calendar entry 403 toemphasize that the travel time 402 is closely tied to the eventrepresented by the calendar entry 403. Alternatively, the travel time402 may be displayed as overlapping just one timeline 443 and positionedon one side of the display 441, for example as spanning the left half ofthe flight event 403 in order to emphasize that the travel representedby the travel time 402 is associated with one location, namely Seattle.The user can also quickly ascertain what the local time will be inChicago when the flight will arrive by referencing where the bottom edgeof shape 402 crosses the Chicago timeline 444.

In contrast to travel events such as flight 403, events that occur injust one location are shown as enclosed shapes having horizontal extentsand placements to overlap just the timeline for that one location. Forexample, the user can quickly grasp that the meeting with Brad 406occurs in Chicago rather than Seattle, as evidenced by the fact that thecalendar entry 406 is an enclosed shape placed on the right side 442 ofthe display and overlaps the timeline 444 for Chicago.

Also shown in FIG. 4 are two meetings 406 and 408 that include traveltime estimates 405 and 407 that allocate time in the calendar to travelto the meetings. In this example, the travel times appear as shapes thatconnect to a top or bottom edge of another calendared event. The traveltimes 402, 405 and 407 can be estimated by the travel time estimationmodule 1273 of the server 120 with reference to map data 12704, businessand organization data 12705, directions and route data 12706, trafficdata 12707, and user location data 12703 as inputs to preparing traveltime estimations. In one embodiment, the travel time estimation module1273 automatically places these travel times 402, 405 and 407 into thecalendar so that they appear as scheduled events to prevent the userfrom double-booking the time before the meeting/event. The travel times402, 405 and 407 also assist the user in planning when the user needs toleave a previous engagement in order to arrive at the next scheduledmeeting/event on time.

FIG. 5 is an illustration of an alternate user interface 500 displayinga calendar showing events in three locations in three different timezones. In other embodiments, more or fewer time zones and locations canbe displayed which allows the user great flexibility in how the userviews calendar entries arranged by location and time. In thisembodiment, the user interface 500 is divided into three portions: theportion on the left 551 corresponding to Pacific Standard Time, theportion in the middle 552 corresponding to Central Standard Time, andthe portion on the right 553 corresponding to Eastern Standard Time. Theon-screen location of the “time box” that represents the event providesa visual cue to the user of what timeline or timelines are relevant tothe event in question. In this embodiment, these time zones have beenchosen because the user is currently in Seattle, in the Pacific timezone, will be traveling to Chicago, in the Central time zone, and alsohas two meetings that include calls to people in New York, the Easterntime zone. A specific city or other location within each of the timezones may or may not be labeled in the portions 551, 552, 553 of theuser interface 500. Each of the three portions includes a respectivetimeline 554, 555, 556 that shows the local time for the locationcorresponding to the respective portion 551, 552, 553. In someimplementations, the locations and time zones are represented in theorder in which they appear on a map as a default organization, but inother implementations they are presented in an order determined by userpreference.

Included in this example are a calendar entry 501 for a conference callwith participants from all three time zones; calls 504 and 509 withparticipants from two time zones each; a flight event 503 that begins inone location (Seattle) and ends in another (Chicago) and requires traveltime 502, and two meeting events 506, 508 that each require travel time505, 507 to attend. Note that in this example, meeting 506 with Brad inChicago includes a call to Tim in New York, hence the calendar entry 506overlaps the timelines for Chicago 555 and New York 556.

FIG. 6 is an illustration of a user interface 600 displaying a calendarshowing events in three locations within the same time zone. The userinterface 600 allows the user to view a visual representation ofcalendar entries according to the location in which the eventsrepresented by those calendar entries occur. The timeline 664 for thePacific Standard Time that applies to all the locations in this exampleis shown along the left of the interface 600, but user interface 600 isstill divided into three parts: the left side 661 represents thelocation of the user's home, the middle 662 represents the location ofthe user's office, and the right side 663 represents Bellevue, alocation to which the user must travel.

The user begins the day at home. In order to attend the morning statusmeeting 602 at the office, an estimated travel time 601 has beeninserted into the calendar to account for the travel time from theuser's home to the office.

According to the calendar shown in FIG. 6, the user plans to call 603 to“Check In with Kids” at 11. Again in this example, dotted lines surroundappointments that do not need to occur at any particular location. Inone embodiment, the calendar events that do not need to occur at anyparticular location are placed so as to overlap the location that thelocation inference module 127 predicts that the user will be based onthe user's patterns. In this example, the conference call 607 overlapsthe office location 662 because the user is generally in the office onFriday afternoons according to the shadow calendar developed by theshadow calendar module 1272 of the location inference module 127.

Travel time 604 is an estimate of the time needed for the user to travelto the delivery location of Sasquatch Books corresponding to event 605in Bellevue from the user's office. Travel time 606 is an estimate ofthe time needed for the user to travel from the delivery location ofSasquatch Books corresponding to event 605 in Bellevue back to theuser's office. Although the user may not have explicitly indicated thatthe user would be traveling back to the office, the location inferencemodule 127 predicts that the user will return to the office based on theuser's past patterns according to the shadow calendar developed by theshadow calendar module 1272 of the location inference module 127. Thelocation inference module 127 also predicts that the user will betraveling home to meet the plumber 609 from the office based on theshadow calendar. Thus, travel time 608 is an estimate of the time neededfor the user to travel home from the office. Travel time 608 is shownoverlapping with conference call 607; however, because the conferencecall could be made during travel (as indicated by the dotted borderaround the conference call 607), the user need not consider this aconflict. On the other hand, if the user is planning on driving home andprefers to not drive while on the phone, the overlap suggests that heshould reschedule either the conference call 607 or the plumber visit609.

FIG. 7 is an illustration of a user interface 700 displaying a calendarshowing events for three users, wherein some events are shared eventsbetween multiple users, in accordance with an embodiment of theinvention. Whereas the examples shown in FIG. 4-6 illustrate userinterface divided into portions representing locations, the portions ofthe user interface 700 of FIG. 7 represent different people.Collectively, locations and people will be referred to herein as“calendar entities.” The user interface 700 allows the user to view avisual representation of calendar entries according to who is involvedin the event represented by those calendar entries. The timeline 774 forthe Pacific Standard Time that applies to the user and the user'sassistant and spouse is displayed along the left of the interface 700,but the user interface 700 is divided into three parts: the left side771 represents the user's own calendar, the middle 772 represents theuser's assistant's calendar, and the right side 773 represents theuser's spouse's calendar. Note that in this example, travel times 701,704, 706, and 711 are presented only on the user's calendar for theuser's calendared events. Note also that only events that involve theuser overlap the timeline 771. The events on the calendars of theassistant 772 and the spouse 773 are placed at the vertical position onthe screen that corresponds to the scheduled time for the event and thehorizontal position on the screen corresponding to the entity/personinvolved in the event.

The user interface 700 includes examples of events 702, 709 and 712 thatinvolve the user and the user's assistant. In a single glance, the usercan grasp where the user and the user's assistant's schedules overlapand when the user's assistant is committed to other responsibilities,like conference call 708. Likewise, the multiple user view of userinterface 700 allows the user to see how the user's schedule lines upthe schedules of others in his life. For example, the user hascalendared a call 703 to check in with the kids before the user's spousetakes the kids to camp 707, and the user must be home to meet theplumber 710 because the user's spouse will be at yoga 713.

FIG. 8 is a flow chart illustrating a method of inferring a geographiclocation of a calendar event, in accordance with an embodiment of theinvention. In step 801, the user's location is tracked. For example, thelocation determination module 115 of the user device 110 determines thelocation of the user device and communicates the location information tothe location tracker 123 of the server 120.

In step 802, places, times, and recurrences are identified from theuser's tracked locations, for example by the place identification module1271 of the location inference module 127. Generally, as a user spendstime in an area, several location readings are communicated from thelocation determination module 115 of the user device 110 to the locationtracker 123 of the server. These location readings are grouped, forexample, by identifying a central location of a plurality of similarlocations readings and a reasonable variance threshold for readings tobe considered to be from the same location. Over time, patterns ofrecurrences develop in the times that a user is reported as being atvarious locations. These observed patterns become the basis for theshadow calendar module 1272 of the location inference module 127 todevelop the shadow calendar. For example, the user may generally betracked around one set of coordinates overnight, and another set ofcoordinates during weekdays from 9-5, and yet at another set ofcoordinates on Saturday nights. Locations where the user repeatedly goesare inferred to have significance to the user, and it is these locationsthat it is desirable to name as places, so that when future plans callfor visiting these places, they can be referred to by the place name andthe travel times to and from the places can be calculated.

In step 803, the identified places are named, for example by the placenaming module 1274 of the location inference module 127. Severaltechniques are used to match what has been observed from the user'spatterns with name of locations that have meaning to the user. Thesetechniques will now be described:

Calendar events are matched 8031 to the identified places based on thetime at which the calendared event was scheduled to occur and theobserved location of the user at that time. For example, the user entersa meeting on Tuesday with a client into his calendar with the locationof “Bob's Office.” Upon attending the Tuesday meeting, the locationinference module 127 observes that the user spends about an hour at anew location, and tentatively associates the name “Bob's Office” withthe new location. Thus, the following week, when the user createsanother weekday meeting having the location of “Bob's Office,” the userinterface may display a pin on a map corresponding to the inferredlocation, and based on the observation that the user is generally atwork during weekdays, the travel time estimation module 1273 canestimate a travel time from the user's work to Bob's Office. Thus, whenthe user saves the calendar entry for the new meeting at Bob's Office,the travel time is also automatically scheduled.

Correspondence is matched 8032 to an identified place based onrecognized event data from the analysis that the event recognitionmodule 126 performs on the user's correspondence. For example, if a userhas received an email that states “Meet me at Sarah's house tonight at7” the event recognition module 126 would recognize that this emailrefers to an event and that the event takes place at a location called“Sarah's House” (as indicated by “at”), starts at 7:00 pm on the currentday (“tonight” indicates both the current day and in the evening), andincludes the sender (“me”). Based on this information, the locationinference module 127 infers that wherever the user happens to be at 7:00pm might be the place known as “Sarah's House” (of course, it might not,if the user ignores the email). Accordingly, when the location inferencemodule 127 observes that the user spends around half an hour at a newlocation at 7:00 that evening, will tentatively associate the name“Sarah's house” with the new location.

Another technique for matching a location visited by the user with aname that has meaning to the user that can be used alternatively oradditionally to the techniques described above is matching 8033 labeledmap data to the identified place. For example, if the user location data12703 indicates to the location inference module 127 that the user hasspent time at a set of coordinates, map data 12704 that corresponds tothose coordinates can be consulted to determine a name associated withthose coordinates, such as the labeled name of the neighborhood, thepark, the lake, the trail, etc. Because location information can have acertain amount of error, because there may be multiple names at or neara set of coordinates, and because we cannot assume that a set of mapdata is complete, associations created this way cannot be certain butare assigned a confidence value depending on the closeness of the matchand degree of certainty. For example, a location in the center of alarge neighborhood results in higher confidence than a location near asmall park, due to the greater likelihood that the user was not at thepark at all.

Data about local businesses 8034 can also be matched to the identifiedplace. Data about local businesses from business and organizational data12705 can be used in combination with other types of data in determiningwhich place from a few possible places that the user spent time. Forexample, the location determination module 115 of John's user device 110reports locations to the location tracker 123 that John is out of theoffice from 12:00-1:00 at a map location that has not been reportedbefore. Data about local businesses shows three businesses within theerror radius of the location readings: a bookstore called “Book Barn,” arestaurant called “Taco Palace,” and a restaurant called “BurgerHeaven.” Based on the fact that John was gone during lunchtime, thelocation inference module 127 has been programmed to infer that it ismore likely that he is visiting a restaurant than a bookstore. John hadalso received an email from Mary that morning that said “lunch today atBurger Heaven?” Therefore, the location inference module 127 concludesthat John went to Burger Heaven with Mary between 12:00-1:00. “BurgerHeaven” becomes a known named place, and the next time John's userdevice 110 reports the locations that could correspond to any of thethree businesses, the location inference module 127 will be more likelyto infer that John visited Burger Heaven than Taco Palace. As with mapdata, matches based on business data can rarely be certain and willresult in associated confidence values depending on the closeness of thematch and corroborating evidence as in the example.

Referring back to FIG. 8, alternatively or additionally, user input ismatched 8035 to the identified place in order to name the place. In oneimplementation, a user's explicit entry of a name for location willoverride any names assigned through inference techniques. In someimplementations, the location inference module 127 will prompt the userto confirm the identified place name is correct, but in others, ahigh-confidence identified place name is assumed to be correct unlessand until the user edits it.

In step 804, the location of a calendared event can be inferred from areference to a named place. Once places the user goes have beenappropriately associated with names that are used to refer to thoseplaces, the location inference module 127 can infer the location of anevent from the name, and the travel time estimation module 1273 cancalculate the time needed to travel to the location. To continue theprevious example, if John sends his buddy Ted a lunch invite and heenters “Burger Heaven” for the meeting location, the GUI 111 can displayan indication to John that the location can be mapped and show thenow-known location of Burger Heaven on a map. Furthermore, the locationinference module 127 will infer that John will be going to Burger Heavenfrom work (since he is usually at work during the day according to theshadow calendar), and provides an estimated 10-minute travel time basedon map data 1204, traffic data 12707, and John's past trips to BurgerHeaven. Thus, as the number of named places that the user has been isbuilt up over time, the location inference module's 127 ability todetermine the location of a place referred to in a future calendar entryis improved, and the travel time estimation module 1273 can estimatetravel times to and/or from the place referred to in that calendar entrywithout additional input from the user.

The present invention has been described in particular detail withrespect to several possible embodiments. Those of skill in the art willappreciate that the invention may be practiced in other embodiments. Theparticular naming of the components, capitalization of terms, theattributes, data structures, or any other programming or structuralaspect is not mandatory or significant, and the mechanisms thatimplement the invention or its features may have different names,formats, or protocols. Also, the particular division of functionalitybetween the various system components described herein is merelyexemplary, and not mandatory; functions performed by a single systemcomponent may instead be performed by multiple components, and functionsperformed by multiple components may instead performed by a singlecomponent.

Some portions of above description present the features of the presentinvention in terms of algorithms and symbolic representations ofoperations on information. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. These operations, while describedfunctionally or logically, are understood to be implemented by computerprograms. Furthermore, it has also proven convenient at times, to referto these arrangements of operations as modules or by functional names,without loss of generality.

Unless specifically stated otherwise as apparent from the abovediscussion, it is appreciated that throughout the description,discussions utilizing terms such as “determining” or the like, refer tothe action and processes of a computer system, or similar electroniccomputing device, that manipulates and transforms data represented asphysical (electronic) quantities within the computer system memories orregisters or other such information storage, transmission or displaydevices.

Certain aspects of the present invention include process steps andinstructions described herein in the form of an algorithm. It should benoted that the process steps and instructions of the present inventioncould be embodied in software, firmware or hardware, and when embodiedin software, could be downloaded to reside on and be operated fromdifferent platforms used by real time network operating systems.

The present invention also relates to an apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored on acomputer readable medium that can be accessed by the computer and run bya computer processor. Such a computer program may be stored in acomputer readable storage medium, such as, but is not limited to, anytype of disk including floppy disks, optical disks, CD-ROMs,magnetic-optical disks, read-only memories (ROMs), random accessmemories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, applicationspecific integrated circuits (ASICs), or any type of media suitable forstoring electronic instructions, and each coupled to a computer systembus. Furthermore, the computers referred to in the specification mayinclude a single processor or may be architectures employing multipleprocessor designs for increased computing capability.

In addition, the present invention is not described with reference toany particular programming language. It is appreciated that a variety ofprogramming languages may be used to implement the teachings of thepresent invention as described herein, and any references to specificlanguages are provided for enablement and best mode of the presentinvention.

The present invention is well suited to a wide variety of computernetwork systems over numerous topologies. Within this field, theconfiguration and management of large networks comprise storage devicesand computers that are communicatively coupled to dissimilar computersand storage devices over a network, such as the Internet.

Finally, it should be noted that the language used in the specificationhas been principally selected for readability and instructionalpurposes, and may not have been selected to delineate or circumscribethe inventive subject matter. Accordingly, the disclosure of the presentinvention is intended to be illustrative, but not limiting, of the scopeof the invention.

What is claimed is:
 1. A computer-implemented method, comprising:obtaining data from a message electronically exchanged between a userand at least one other user; identifying, in the data, an identifier anda time; and as a result of location data of a device associated with theuser satisfying a set of conditions based at least in part on the time,assigning the identifier to the location in data for an electronic map.2. The computer-implemented method of claim 1, wherein the identifier isa name of a place.
 3. The computer-implemented method of claim 1,wherein assigning the identifier to the location comprises associatingthe identifier with global positioning system coordinates in a datastore.
 4. The computer-implemented method of claim 1, wherein themessage is formatted according to a calendar application.
 5. Thecomputer-implemented method of claim 1, wherein the set of conditionsare further based at least in part on data associated with the locationfrom a source different from the message.
 6. The computer-implementedmethod of claim 1, wherein the set of conditions are based at least inpart on the location data of the device indicating the device beinglocated at the location.
 7. The computer-implemented method of claim 1,wherein the location is a geographical area.
 8. A system, comprising:one or more processors; and memory storing instructions executable bythe one or more processors to cause the system to: obtain data from amessage electronically exchanged between a first user and a second user,the data indicating an identifier and a time; determine satisfaction ofa set of conditions based at least in part on the time and location dataof a device; and associate the identifier to the location to be usedwith an electronic map.
 9. The system of claim 8, wherein theinstructions are further executable to cause the system to receive thelocation data from the device.
 10. The system of claim 8, wherein theidentifier comprises a name associated with a geographic area.
 11. Thesystem of claim 8, wherein the device is associated with the first user.12. The system of claim 8, wherein the set of conditions are furtherbased at least in part on another message electronically exchangedbetween a third user and second user.
 13. The system of claim 8, whereinthe message is an electronic mail message or text message.
 14. Thesystem of claim 8, wherein the instructions are further executable tocause an event to be associated with the location.
 15. A non-transitorycomputer-readable storage medium having stored thereon instructionsthat, if executed by one or more processors, cause a system to:obtaining an identifier and a time based at least in part on a messageelectronically exchanged between a first user and a second user; and asa result of location data of a device associated with the usersatisfying a set of conditions based at least in part on the time,assigning the identifier to the location in data for an electronic map.16. The non-transitory computer-readable storage medium of claim 15,wherein the instructions, if executed, further cause the system tosolicit confirmation of assignment of the identifier to the locationfrom the first user.
 17. The non-transitory computer-readable storagemedium of claim 15, wherein assigning the identifier to the location.18. The non-transitory computer-readable storage medium of claim 15,wherein the data for the electronic map is specific to the first user.19. The non-transitory computer-readable storage medium of claim 15,wherein the instructions, if executed, further cause the system toassign another identifier to the location such that the identifier andthe other identifier are both associated with the location.
 20. Thenon-transitory computer-readable storage medium of claim 15, wherein thelocation lacks an assignment of an identifier prior to assignment of theidentifier by the system.